Video cataloger system with hyperlinked output

ABSTRACT

One aspect of the invention is directed to a system and method for video cataloging. The video is cataloged according to predefined or user definable metadata. The metadata is used to index and then retrieve encoded video. In another aspect of the invention, video metadata track processors convert metadata tracks of the video information to produce displayable frames containing hyperlinking between displayable data. Another aspect of the invention is directed to a method of browsing stored video information, including displaying hyperlinked frames of metadata track representations, and selecting and displaying links between displayable frames.

PRIORITY

The benefit under 35 U.S.C. § 119(e) of U.S. provisional applicationSer. No. 60/055,751, filed Aug. 14, 1997, is hereby claimed.

RELATED APPLICATIONS

The subject matter of U.S. patent applications: application Ser. No.09/134,498, filed Aug. 14, 1998 and entitled “VIDEO CATALOGER SYSTEMWITH EXTENSIBILITY”; application Ser. No. 09/134,497, filed Aug. 14,1998 and entitled “VIDEO CATALOGER SYSTEM WITH SYNCHRONIZED ENCODERS”;and application Ser. No. 09/134,500, filed Aug. 14, 1998 and entitled“VIDEO CATALOGER SYSTEM WITH AUDIO TRACK EXTRACTION” are related to thisapplication.

GOVERNMENTAL RIGHTS

This invention was made with Government support under Contract No.DAAH01-97-C-R190, awarded by U.S. Army Aviation and Missile Command andContract No. DAAH01-96-C-R121, awarded by U.S. Army Missile Command. TheGovernment may have certain rights in this invention.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to asset management of digitalmedia, and more specifically, to a system and method for capturing andmanaging video and associated data.

2. Description of the Related Technology

Today's broadcast corporations, advertising agencies, consumer productsand services companies, and other businesses have demanding media assetmanagement needs. These organizations have been simultaneously empoweredby the growth in tools and infrastructure for creating, storing andtransporting media-rich files and challenged by the problem of managingthe media assets that they've amassed and come to rely upon for theircore businesses. The sheer volume of information available over theWorld Wide Web and corporate networks continues to accelerate. Becausemedia assets are so crucial to these companies, they have an extremeneed for an intelligent and efficient way to catalog, browse, search andmanage their media assets. Prior attempts at a content managementsolution have yielded point solutions or proprietary applications. Theseapplications have not leveraged the technologies already deployed bymany organizations, such as industry-standard browsers and Web servers.

A system is needed that would automatically watch, listen to and read avideo stream so as to intelligently extract information, termedmetadata, about the content of the video stream in real-time. Thisinformation would become the foundation of a rich, frame-accurate indexthat would provide immediate, non-linear access to any segment of thevideo. Such a logging process would result in the transformation of anopaque video tape or file, with little more than a label or file name todescribe it, into a highly leveragable asset available to an entireorganization via the Internet. What was once a time consuming process tofind the right piece of footage would be performed instantly andeffortlessly by groups of users wishing to quickly and efficientlydeploy video across a range of business processes. Television and filmproduction, Web publishing, distance learning, media asset managementand corporate communications would all benefit by such technology.

SUMMARY OF THE INVENTION

In one aspect of the invention, there is a media cataloging and mediaanalysis application which performs real-time, or non-real-time,indexing and distribution of video across an enterprise. A multimediacataloger is the first application to make video-based solutionspervasive in enterprise markets by creating and publishing intelligentvideo via the World Wide Web. The multimedia cataloger is the logicalstarting point for creating or distributing significant amounts ofvideo. The cataloger transforms video into a powerful data type that isboth compelling and profitable in both Web and client-serverenvironments. Using advanced media analysis algorithms thatautomatically watch, listen to and read a video stream, the multimediacataloger intelligently extracts metadata-keyframes, time codes, textualinformation and an audio profile from the video in real-time. Thisinformation becomes the foundation of a rich, frame-accurate index thatprovides immediate, non-linear access to any segment of the video.

In parallel to the indexing process, the multimedia cataloger may alsooptionally control the encoding of a streamable version of the originalcontent. Synchronized encoding and indexing allows users tointelligently navigate through the video by using the index to godirectly to the exact point of interest, rather than streaming it fromstart to finish. This approach provides video previewing that is fasterthan real-time, conserves valuable network bandwidth and dramaticallyreduces costs associated with editing and repurposing video.

The multimedia cataloger permits accessing and distributing media fordigital television, Web publishing, distance learning or media assetmanagement initiatives using advanced methods for accessing andleveraging media assets.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one embodiment of a multimedia catalogersystem of the present invention.

FIG. 2 is an exemplary screen display of a user interface for themultimedia cataloger system shown in FIG. 1.

FIG. 3 is a block diagram of exemplary input and peripheral componentsfor the multimedia cataloger system shown in FIG. 1.

FIG. 4 is a block diagram of exemplary components and processes used inthe cataloger and encoder portion of the multimedia cataloger systemshown in FIG. 1.

FIG. 5 is an exemplary timeline of encoder start-up and synchronizationfor the components and processes shown in FIG. 4.

FIG. 6 is a diagram of an exemplary set of metadata types in atime-based track representation as derived by the cataloger of themultimedia cataloger system shown in FIG. 1.

FIG. 7 is a block diagram of an object model for the metadata shown inFIG. 6 along with a software process that manages the metadata.

FIG. 8 is a block diagram of the software architecture for the catalogerof the multimedia cataloger system shown in FIG. 1.

FIG. 9 is a block diagram of the elements of the extensible video engineshown in FIG. 8.

FIG. 10 is a block diagram of the audio analysis extractor shown in FIG.9.

FIG. 11 is a flowchart of the extensible video engine initialization(start-up extensibility initialization) process shown in FIG. 8.

FIG. 12 is a flowchart of the video encoding (and metadata capture)synchronization process shown in FIG. 8.

FIG. 13 is a flowchart of the capture metadata process shown in FIG. 12.

FIG. 14 is a flowchart of the feature extraction process shown in FIG.13.

FIG. 15 is a block diagram of the architecture of the HTML output filtershown in FIG. 9 as used in the multimedia cataloger system shown in FIG.1.

FIG. 16 is a flowchart of a HTML output filter process corresponding tothe HTML output filter architecture shown in FIG. 15.

FIG. 17 is an exemplary screen display seen as an output of the HTMLoutput filter process of FIG. 16 while using a client browser for themultimedia cataloger system shown in FIG. 1.

FIG. 18 is a block diagram of another embodiment of a multimediacataloger system of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following detailed description of the preferred embodiments presentsa description of certain specific embodiments to assist in understandingthe claims. However, the present invention can be embodied in amultitude of different ways as defined and covered by the claims.Reference is now made to the drawings wherein like numerals refer tolike parts throughout.

The detailed description is organized into the following sections: 1.Top Level System Overview, 2. Example User Interface, 3. CatalogerConfiguration Detail, 4. Logging and Encoding, 5. Example Timeline, 6.Metadata Track Representation, 7. Metadata Index Object Model, 8.Cataloger Architecture, 9. Extensible Video Engine Architecture, 10.Audio Feature Extractors, 11. Extensible Video Engine Start-upInitialization, 12. Video Encoding and Metadata Synchronization, 13.Capture Metadata, 14. Feature Extraction, 15. HTML Output FilterArchitecture, 16. HTML Output Filter Process, 17. Example HTML Output,18. Alternative System. Before describing the detailed internalengineering of the inventive system, a top level system overview will behelpful.

1. Top Level System Overview

FIG. 1 depicts a typical system 100 that incorporates a Video Cataloger110. The Video Cataloger 110 typically operates in a networked envi datacommunication lines 112, 122, 132, and 142. Some variants of such asystem include:

Analog Sources 102: may be any of a number of possible sources, such asan analog or digital tape deck, a laser disc player, a live satellitefeed, a live video camera, etc. A video signal, such as NTSC or PAL, isall that is needed for input into the Video Cataloger 110.

Metadata Server 130: may be as simple as a file system containinghypertext markup language (HTML) files, or as complex as a relationaldatabase supporting a client-server application environment for mediamanagement. Client interfaces may be HTML web browsers, Java, or nativeclient applications, for example.

Digital Video Encoding 120: the existence of digital video is anoptional component. It may be the case that the metadata merely indexesvideo that resides on analog video tapes stored on shelves.

Content Server 140: may be as simple as a file system containing digitalvideo files, or as complex as a digital video stream server such asthose offered by Real Networks, Silicon Graphics Mediabase, Oracle OVS,and the like.

Digital Video Formats: digital video data is encoded by an encoderprocess 120 and communicated to the Content Server 140 over a networkchannel 122. The format of the digital video may be any of a widevariety of formats, such as Real Video (at various bit rates from 20kbps up to 500 kbps), MPEG-1 (at various bit rates up to 3.5 mbps),MPEG-2 (at various bit rates up to 40 or 50 mbps), MPEG-4, MPEG-7,Motion JPEG, Apple QuickTime, Microsoft AVI, and so forth.

2. Example User Interface—Screen Shot

FIG. 2 depicts an example user interface that is representative of thetype of graphical user interface (GUI) than could be built around theVideo Engine shown in FIG. 9. In FIG. 2, the Video Cataloger userinterface is contained in a window 170. The main controls are exposed asmenus and a tool bar 182. A panel 172 displays the live video beingdigitized, with play, stop, etc. controls that interact remotely withthe analog source via a deck controller 240 (FIG. 3). Keyframesextracted during the capture process are displayed in a panel 176, whilethe corresponding close-caption text and timecodes are displayed in apanel 178. A panel 184 displays the user-defined clip annotations,created by marking in- and out-points. The columns 186 and 188 displaythe in- and out-time codes for the marked clip, respectively, while theremaining columns 190, 192, 194 are an example of a user defined schemaof labels to describe the clip. Finally, at the bottom of the window 170is a timeline 180 that depicts the total time of the capture session,with a highlighted section corresponding to the currently selected rangeof keyframes.

3. Cataloger Configuration Detail

FIG. 3 depicts a typical configuration of the Video Cataloger 110connected to various peripheral devices that interface the Cataloger toan analog source such as the videotape deck 102, a Deck Controller 240,and a close caption decoding device 230. The deck controller 240 istypically an external device that provides protocol translation betweenan industry standard protocol such as V-LAN, and the native protocol ofbroadcast devices (such as tape decks) from Sony, Panasonic, etc. Anexample device is the Video Media Express from Video Media Corp. Somehardware configuration may incorporate the V-LAN controller into a cardin the Cataloger workstation, for instance.

The close caption text decoder 230 can be an external box as shown,(such as EEG Enterprises Digital Recovery Decoder), or the CC-textdecode functionality can be incorporated on the frame capture boardinside of the Cataloger workstation. Furthermore, the video signal maybe routed through the close caption text decoder 230 (as shown), or itmay be split and fed directly to both the video Cataloger 110 and thedecoder in parallel.

The Video Deck 102 is one example of an analog source. Several othersare possible: laser disk, satellite feed, live camera feed, digital diskrecorder such as a Tektronix Profile, etc. Some of these configurationswould not incorporate the V-LAN control (such as a live or satellitefeed).

Analog signals 232 may be fed from the Video Deck 102, through the closecaption decoder 230, into the Video Cataloger 110. The analog signalscorrespond to video information which generally includes audioinformation. Decoded close caption text is passed to the Video Cataloger110 by a data connection 234 which is typically an RS-232 cable. Deckcommands pass from the Video Cataloger 110 to the Deck Controller 240,and then to the Video Deck 102 by physical data connections 236 and 242which are typically RS-232 serial connections, but may be othersignaling protocols. The time codes proceed from the video deck 102 tothe video cataloger 110 via the deck controller 240. Of course, inalternate implementations, the Video Cataloger 110 may receive videoinformation from a digital source such as a digital camcorder.

4. Logging & Encoding—Detail

Overview

FIG. 4 depicts one of a great variety of possible encoding scenarios,driven by the Video Cataloger. The Video Cataloger software 110 runs ona computer workstation 111. The “Vidsync” process 260 running on each ofthe encoder workstations 123, 125, 127 is responsible for responding toStart and Stop commands from the Video Cataloger 110, and affecting thestart and stop of the corresponding encoding process on eachworkstation. The analog source 102 will typically need to be split by anaudio-video switcher 252 so that the signal can be fed to each receivingworkstation without degradation. FIG. 4 shows examples of Real Videoencoding 124, MPEG-1 encoding 126, and MPEG-2 encoding 128. Furtherinformation on the Moving Pictures Experts Group (MPEG) encodingstandards may be found at the following URL:http://drogo.cselt.stet.it/mpeg. Naturally, other encoding formats arepossible. All machines are connected by a data network 250, which istypically a TCP/IP network, although other network protocols may beemployed. Some of the many variations for encoding scenarios include:

a. Incorporation of an encoder hardware board 126 (such as an MPEG-1encoder from Optibase, Minerva, etc.) directly inside the VideoCataloger workstation 111. Because most of the computation occurs on thededicated board, this is feasible in practice)

b. Use of a stand-alone “black-box” encoder such as those from Lucentand Innovacom for MPEG 1, which do not require a workstation. Theblack-box simply accepts an analog input, and a network connection todeliver the MPEG data packets to a video server. These boxes aretypically rack mounted, and can be configured with up to eight encodersper enclosure. This is ideal for large scale encoding scenarios whereseveral feeds or tape decks must be encoded.

c. Using one, two, or N encoders simultaneously. For simple browseapplications, a single encoded proxy is all that is needed. For webpublishing applications, publishers typically want to encode alow-resolution stream (such as Real Video at 20 kbps) and a highresolution stream (such as Real Video at 100 kbps) to service differentusers having different Internet connection bandwidths.

Command Structure

The Cataloger 110 issues commands to each of the Vidsync daemons 260running on the encoder workstations. These daemons, or processes thatare periodically spawned to carry out a specific task and thenterminate, are responsible for initiating the encoding process forwhatever type of encoding is going to occur. That is, intimate knowledgeof the encoding is maintained in Vidsync, and the Cataloger is genericin this respect. The Vidsync daemons also are responsible for returningcertain pieces of information to the Cataloger, such as the actual starttime, and a digital video asset ID or name for later use.

START Command: The Cataloger 110 issues a “start encoding” command viaTCP/IP to each of the encoders (Vidsyncs) in parallel. Each of theVidsyncs 260 then communicates with whatever software and hardwareencoding processes/boards are required to initiate encoding. This mayalso involve communicating with a video server to set up an encodingsession, and may take from 1 to several seconds. Thus, each encoderprocess may have a different actual start time. The Vidsync daemons thenreturn the actual start time and a digital video asset ID to theCataloger 110. When all Vidsyncs 260 have returned, the metadata capturebegins at a nominal T=0 time. Each of the actual start times is storedas a delta-time from this T=0 time. When a piece of metadata (such as akeyframe) is used to index the digital video, an absolute time from thebeginning of the digital video is computed by adding the delta-time tothe time-code of the metadata.

STOP Command: The Video Cataloger 110 issues a “stop encoding” commandvia TCP/IP to each of the encoders in parallel.

5. Example Timeline

FIG. 5 illustrates the timing associated with video encoder start-up andsynchronization. Each timeline 123, 125, 127 represents a separate videoencoder. The Video Cataloger 110 issues a Start Command 290. Some timeafter that, each encoder actually begins encoding, resulting in an“actual start time” 292. After all the encoders have started, the VideoCataloger 110 itself begins cataloging metadata, at a time nominallylabeled “T=0” 294. Thus, each encoder has a start offset ‘delta’ time296. This delta time is then stored with the video metadata to be usedlater when a video stream is requested, to insure the offset isaccounted for in time code calculations.

6. Metadata Track Representation

FIG. 6 is a logical illustration of a number of metadata types in theform of the preferred time-based track representation. The keyframetrack 320 consists of a set of individual keyframes 340, 342, 344, 346,348, 350, 352 which have been intelligently extracted from the videobased on visual information and scene changes by the Keyframe Extractor512 (FIG. 9). Each keyframe is time stamped for later correlation withthe digital video or a time-code on a videotape.

The close caption text (cc-text) track 322 consists of sentences of textparsed from the cc-text input by the cc-text extractor 514 (FIG. 9).Each text element spans a period of time in the video, denoted by anin-time and an out-time.

Likewise, the remaining metadata tracks (Audio Classes 324, Speech 326,Speaker ID 328, Keywords 330) are each a parcel of metadata spanning atime period, and are extracted by their corresponding feature extractorshown in FIG. 9.

The Clip Track 332 is somewhat unique in that the definition/creation ofthis metadata is performed by a user using the GUI to mark in- andout-times, and type in associated alphanumeric data. Each bar in theClip Track consists of a user-defined group of metadata fields that areapplication specific. The bar length is timespan from intime to outtime.Clips may be overlapping. Typically, the clips all have the same schema.For instance, metadata may include: Story Title, Report, Location, ShotDate, Air Date, Keywords, Summary, and so on. Each bar shows a cliplabel. So for instance, the clip labelled “Logo” may make use of theStory Title data item. Lastly, a Custom Trk is shown to indicate thatmetadata is extensible. That is, unique metadata can be defined andadded to the Video Cataloger 110 by a user. Custom metadata tracks couldinclude information provided in collateral data to the videoinformation. For instance, global positioning satellite (GPS) dataspecifying latitude and longitude of a video camera and telemetry dataof a vehicle carrying a video camera are examples of such collateraldata.

7. Metadata Index Object Model

FIG. 7 is an Object Model of the same logical metadata illustrated inFIG. 6. The elements of this diagram depict the software objects andprocesses that manage this metadata. The main object, the Metadata TrackIndex Manager 402, is the manager of the entire index of metadata. It isextensible in that it allows registration of individual metadata trackdata types, and then manages the commitment of instances of that datainto the index by feature extractors. There is one global metadatastructure (the Session Level metadata 404) that is not time based, andcontains metadata that pertains to the entire video. Here, for example,is where the information for managing and time-synching the encodedvideo resides (digital video ID's and actual start time offsets). Userdefined annotations may also exist here. Each of the metadata tracks isa collection of data objects 406, 408, 410, 412, etc. that hold themetadata for a specific feature extractor, and are sequenced in timeaccording to their in- and out-times.

The metadata index also provides access for outputting metadata (dataread-out) used by the Output Filters.

In an object oriented programming implementation, every Track data typeis derived from a “virtual base class” that provides the basic functionsfor insertion, deletion, read-out, etc., and defines storage for thein-time and out-time of each metadata element. Such an implementationmay be coded in the C++ programming language. One exemplary referenceguide is C++ Primer by Stanley Lippman, Second Edition, Addison Wesley,which is hereby incorporated by reference.

TABLE 1 Track Data Types Metadata Data Track Type Notes Virtual Baseuntyped Defines In-time and Out-time for all Class (void*) tracksKeyframe image (bitmap) In-time equals Out-time, i.e., keyframe Track isa point in time CC-text Track Text fragment Each text fragment istypically a sentence (but not required to be so) and spans a timeinterval Audio Class Enumerated Speech, Silence, Music, Applause, TrackClasses Siren, etc..., each spanning a time interval when thatclassification was valid Speech Track Text fragment Each text fragmentspans a time interval Keyword Track Word (text) keyword utterance spansa short (1/2 sec) time interval Speaker ID Enumerated Identifiers ofindividuals whose Track Classes speech is recognized... each Speaker IDspans a time interval when that speaker was speaking Clip Track LabelSet (user Different Label Set schemas can be defined set of used indifferent applications. Each labels): Text, Label Set is applied to allclips within Enums, Dates, a Cataloging session. The Clip Numbers, etc.definition spans a time interval marked by the user. Each Label fieldvalue is entered manually by the user. Custom Data type Typically, acustom metadata defined by generator uses a custom track data plug-intype for storing its metadata. It could also re-use existing track datatypes such as Text Fragment.

Table 1 is a summary of the various standard metadata tracks, detailingthe data types of each, and providing descriptive notes.

8. Video Cataloger—Architecture

FIG. 8 is a global architecture illustration of the entire VideoCataloger software process 420. The main components of this software arethe Media Capture Services 430, the Video Encoding and Synchronizationfacility 450, the Start-up Extensibility Initialization manager 470, andthe core Extensible Video Engine component 440. The details of the coreExtensible Video Engine 440 are provided in FIG. 9. The Video Encodingand Synchronization module 450 is responsible for communicating with the“Vidsync” daemon processes running on the video encoders, e.g., 123, 125and 127 (FIG. 4). The Media Capture Services 430 are further describedin conjunction with FIG. 9.

The registration interfaces for the extensible aspects of the ExtensibleVideo Engine 440 are explicitly shown in FIG. 8. Upon start-up of theVideo Cataloger 110, registration processes are invoked for the fourprimary extensibility aspects of the Video Cataloger: Metadata trackregistration 476, Feature Extractor registration 472, Output Filterregistration 478, and Event registration 472. A set of output filters484 are installed during system start-up. These registration processes,as well as user input and output functions 550, 554, are furtherdescribed in conjunction with FIG. 11 below.

9. Extensible Video Engine—Architecture

FIG. 9 depicts the main architectural elements of the extensible VideoEngine 440. Incoming media is processed by the Media Capture Services430 consisting of Timecode Capture 502, Video Capture 504, Audio Capture506, and Text Capture 508. Digital media 509 is then made available tothe Feature Extractor Framework 510 for processing. Metadata from theFeature Extractors 512, 514, 516, 518, 520, 522 is then committed to theMetadata Track Index Manager 530 in a time based track representation asshown in FIGS. 6 and 7.

During metadata capture, the user may mark video clips and annotatethem. This input 552 is captured by the GUI Input Capture element 550.Event monitoring 540 and dispatch 544 also occurs during capture, drivenby an Event Dictionary 542. Finally, when capture is complete, themetadata may be output in a variety of formats such as Virage DataFormat (VDF) 562, HTML 564, XML 566, SMIL 568 and other 570, which aremanaged by the Output Filter Manager 560. A VDF API and Toolkit may belicensed from Virage of San Mateo, Calif. Furthermore, the use of theformat is described in “Virage VDF Toolkit Programmer's Reference”. Onereference for the eXtensible Mark-up Language (XML) is the followingURL: http://www.w3.org/TR/REC-xml which is a subpage for the W3C. Also,information on Synchronized Multimedia Integration Language (SMIL) maybe accessed at the W3C site.

The Metadata track Index Manager 530 represents the object that managesthe multiplicity of metadata tracks. When data is committed to the trackindex by either a feature extractor 512-522 or GUI input 550 and 552(i.e., user marks clips and annotates them), this can trigger displayupdates as follows: the particular metadata track that receives the datadecides if this requires a display update. If so, it sends a message tothe GUI Display Update Manager 554 which marks the relevant GUI objectas “dirty” and in need of a redraw. In Windows Microsoft FoundationClasses (MFC), the event model allows Windows to detect these dirty GUIobjects and issue redraw messages to them directly (see FIG. 12—GetEvent)

The core aspects of extensibility are:

Extensible Track data types are registered with the Metadata Track IndexManager 530. Any desired data representation can be defined andinstalled, such as region markers, OCR text and confidence values, faceidentifiers, camera parameters (pan, tilt, zoom), etc. Any property thata feature extractor chooses to extract can be placed in a custommetadata track.

Extensible Feature Extractors can be registered with the FeatureExtractor Framework 510 to operate on digital media, or on anycollateral data they may choose to collect when called.

Extensible Event triggers: event criteria (e.g., cc-text == “clinton”,or audio_class ==“tone”) can be registered in the Event Dictionary 542,and arbitrary actions can be registered and triggered (e.g., grab akeyframe right then, or stop capture). The Event Monitor 540 monitorsthe incoming metadata to decide if an event is triggered. If so, itsends a message to the Event Dispatcher 544 which invokes thecorresponding action 546 for the event.

Extensible Output Filters may be registered with the Output FilterManager 560. Further discussion of Output Filters is provided below withrespect to FIGS. 15 and 16.

Time code capture 502 is typically via VLAN (as in FIG. 3), but may comefrom a variety of sources. Time code capture is another aspect ofextensibility (though not core) since we have a plug-in for time-codeextraction

10. Audio Feature Extractors

FIG. 10 depicts the architectural components of the audio analysisfeature extractors 516 in one embodiment of the Video Engine 440. As canbe seen in the diagram, there are various cross-couplings between thesefeature extractors, which may not be precluded in the extensibilitymechanisms managed by the feature extractor framework 510 (FIG. 9).

The analog audio signal 592 is captured and digitized by audiodigitization device 506, which may be any standard audio digitizationdevice, such as a Sound Blaster audio card for a PC. The digital signalis then normalized by a software component 596 to account forvariability in signal amplitude (volume). The normalized digital audiosignal 598 is then fed into an Audio Class Profiler 600 which classifiesthe signal into one of several possible categories, such as “speech”,“music”, “silence”, “applause”, etc., where each of the categories maybe trainable using well understood techniques, and is stored in a ClassDictionary 602. An Audio Classification (AC) Engine 604 is a modularcomponent that is available from multiple vendors, or may beproprietary. One skilled in the relevant technology may evaluate andutilize a specific engine depending on the application requirements.

When the Audio Class Profiler 600 detects that the class is “speech”, ittriggers switch 610 which then allows the normalized digital audiosignal 598 to pass into additional feature extractors which are capableof processing speech. A speech transcription module 620 is designed tointerface with any available Speech Recognition Engine 624 using anindustry standard interface 626, such as the “Speech API”, or SAPIdefined by Microsoft. Typically, the Speech Recognition Engine 624utilizes a Vocabulary Dictionary 622 to aid in the speech recognitionprocess and improve accuracy by limiting the speech domain, althoughthis is not required. It is a typical feature of existing speechrecognition engines available on the market today. Examples includeofferings from IBM, BBN, Dragon Systems, SRI, and so on.

The output of the Speech Transcription Feature Extractor 620 may then befurther processed as follows: the full text 628 of the transcriptionprocess may be used directly as metadata; additionally, a KeywordSpotting Feature Extractor 640 may be employed to selectively identifykeywords of interest, and produce a text output 648 limited to thekeywords specified by a Domain Dictionary 642. A Domain DictionaryEngine 644 is responsible for making these selections. Again, the DomainDictionary 644 Engine is typically a modular component that may be oneof several available, interfacing with the Keyword Feature Extractornormally via a standard interface 646 such as the Domain Dictionary API,or DDAPI.

The normalized digital audio signal containing speech can also be fedinto a Speaker ID Feature Extractor 630 to identify individual speakersby name. A Speaker ID Engine 634 may also be a modular component that isoffered by several speech recognition vendors, and interfaces with theSpeaker ID Feature Extractor 630 typically via an industry standardinterface 636 such as the SVAPI. Typically, the Speaker ID Engineutilizes a Speaker Dictionary 632 to constrain the space of possiblespeakers, and store signatures or sample speech of individual speakerswhich are used during speaker identification.

11. Extensible Video Engine Start-up Initialization—Flowchart

FIG. 11 is the process flowchart for the start-up initialization of theVideo Cataloger 110 (FIG. 1). This flowchart depicts the process forregistering data types, algorithms, and events which are important tothe extensibility features of the Video Cataloger 110.

Upon start-up of the Video Cataloger, the extensible video engineinitialization process 470 is executed by the workstation 111. Startingat a begin step 702, the process 470 moves to step 704 to installmetadata tracks. This occurs first since later extensions (mainlyFeature Extractors) may then utilize the, track data types previouslyinstalled. Built-in Track Types are installed first at step 704,followed by installation of custom track types defined by plug-inmodules at steps 706 to 710. For each track plug-in, the datarepresentation defined by that plug-in is installed at step 708.

Next, feature extractors are installed. The built-in feature extractorsare first installed at step 714, followed by feature extractors definedby plug-ins at steps 716 to 722. For each plug-in feature extractor, itis first registered at step 718 with the Feature Extraction Framework510 (FIG. 9). At step 720, each of these plug-in feature extractors mayrequest a metadata track type to receive its metadata.

Following the feature extractor initialization, the Output Filters areinitialized. As with the other elements, the built-in Output Filtersare, installed first at step 724, followed by the installation ofplug-in Output Features at steps 726 to 730.

Finally, Events are registered. All events are application specific(i.e., there are no built-in events), and are registered by plug-insstarting at steps 734 to 740. Each plug-in may define one or more eventsin the dictionary at step 736, and each event will have an associatedevent handler registered with it at step 738. The extensibilityinitialization process 470 completes at an end step 742.

12. Video Encoding/Synchro—Flowchart

FIG. 12 details an important aspect of the present invention, which isthe control and synchronization of the video encoding process with themetadata capture process. This synchronization is necessary becausetime-code indices within the metadata elements should correspond tocorrect and known points within the digital video that results from theencoding process.

When video capture is initiated by the user, the video encoding process450 starts at a begin step 762 and moves to step 764 wherein the VideoCataloger 110 (FIG. 1) first issues a Start Encoding command to each ofN video encoders in parallel by spawning process threads 766 for eachencoder present. A process thread or a lightweight process is wellunderstood by computer technologists. This command/control is effectedby the “Vidsync” daemon process 260 (FIG. 4) running on each encoderstation. These Start commands are issued in parallel so that all theencoders begin encoding as close together in time as possible. However,their exact start times will not in general, be coincident. For thisreason, the Vidsync process 260 returns the actual start times to theencoder flow control, and these times are stored by the Video Cataloger110 with the video metadata in step 774 for later use. Next, the generalprocess of capturing metadata occurs in step 776 until the process isstopped by the user. The details of the metadata capture process 776 areprovided in FIG. 13. When capture is done, Stop Encoding commands aresent in parallel to each encoder (via Vidsync) by spawning processthreads 780. It is of no consequence that the N encoders may stopencoding at slightly different times, as no metadata is associated withthese time intervals.

13. Capture Metadata—Flowchart

FIG. 13 details the metadata capture process 776 which is an importantactivity of the Video Engine 440 of FIG. 9. The metadata capture process776 was first introduced in FIG. 12.

The capture process 776 begins with the scheduling of a system timerevent in step 804 set to go off {fraction (1/30)} of a second in thefuture. The control flow of the process 776 immediately proceeds to theGet Event step 806 where other system events (besides the timer event)may be processed. When an event occurs, control passes to the EventDispatcher 808 which decides if the event is one of the two types ofevents: a normal GUI event, or the scheduled timer event.

For a GUI event, the event is first inspected in step 812 to determineif it is an End Capture event, in which case the capture process loopterminates. If not, processing proceeds to step 816 to handle the GUIevent (such as keystroke, window resized, etc.). Some GUI events maygenerate metadata (if the user marked a video clip), which is determinedin step 818. If metadata (a video clip) was in fact generated, thatmetadata is committed to the Metadata Track Index Manager 530 (FIG. 9)during step 820. This also necessitates a GUI redraw, so the affectedparts of the GUI are marked for Redraw in step 822.

If the event dispatched in 808 is the timer event., this signifies thatfeature extraction of metadata from the video signals is to take placeat a feature extraction process 810. The details of the featureextraction process 810 are provided in conjunction with FIG. 14. Oncefeature extraction is complete, control moves to step 804 where the nexttimer event is scheduled.

This flow of activity is tied to the event model of the operating systemunder which the software application is running. The flow that is shownis an event model that is typical of a Windows MFC-based application.Other operating system platforms, such as Unix, have event models thatdiffer somewhat. The event model illustrates how the feature extractionprocess fits into an application event framework. Note that, in thedepicted embodiment, the Get Event task 806 is a call out to WindowsMFC, which processes Redraw Events by calling the Redraw method of theappropriate GUI elements directly (this process diagram does not “call”the Redraw methods directly). Note that it is acceptable if featureextraction takes more than {fraction (1/30)} second.

14. Feature Extraction—Flowchart

FIG. 14 details the feature extraction process 810, which is animportant aspect of the present invention, relying on the innovativearchitecture of FIG. 9.

The feature extraction process 810 begins at a start step 842 andproceeds to step 844 where the current time code is obtained by module502 of FIG. 9. This time code is used by all feature extractors totime-stamp the metadata they extract. Next, all digital media iscaptured in step 846 by modules 504, 506, and 508 of FIG. 9. Thisdigital media is then passed on to the Feature Extractor Framework 510(FIG. 9) for processing. The Feature Extractor Framework 510 spawns aprocess thread 850 for each feature extractor. Each feature extractorprocesses the digital media in step 852 in whatever way it desires, forexample, extract a keyframe, classify the audio signal, etc. In certaincases, but not all, some metadata will be generated from this process.Step 854 determines if this is the case, and if so, the metadata ispassed to the Metadata Track Index Manager 530 (FIG. 9) during step 856.Since metadata is usually displayed in real-time in the GUI, the GUI ismarked for redraw in step 858. One particular exemplary feature:extractor for video keyframes is described in the pending U.S. patentapplication entitled “Key Frame Selection” filed on Jun. 6, 1997.

When all feature extractor threads complete, as determined at wait(synchronization) step 862, control is returned to the capture metadataprocess at end step 864.

15. HTML Output Filter—Architecture

The Output Filter Manager 560 (FIG. 8) may utilize a HTML output filter564 in one embodiment. Referring to FIG. 15, elements of FIGS. 1, 2 and9 are shown together as utilized in generating HTML output. The user mayinvoke a GUI command such as the “Save-As” command on the “File” menu553, which in turn provides a list of output filter choices (HTML, RealNetworks SMIL, XML, custom, etc.). When the HTML filter 564 is invoked,it accesses the metadata in the Metadata Track Index Manager 530 andprocesses it into HTML form in a browser window 916 (FIG. 17), whichalso involves keyframe images in a keyframe frame 176 (FIG. 2) or 904(FIG. 17), and the digital video 142 (FIG. 1) or as seen in a videoframe 896 (FIG. 17). For instance, hyperlinks may be formed fromdisplayed keyframes to video sequences. The digital video 142 may or maynot be served by a content server 140. For instance, it could be asimple file on the file system of the client computer or, say, anetworked mass storage device visible to the computer.

Some key features of the Video Cataloger HTML output are:

a. The HTML files used to generate the display in the browser window 916(FIG. 17) are completely stand-alone, internally linked HTML, such thatno Web server is required. Exemplary HTML files are provided in theAppendix and are described in conjunction with FIG. 17 below.

b. It incorporates play-back of digital video 142 from a file or from avideo server 140. That is, the digital video may be streamed directly tothe browser, or it may simply be played from a local file on disk. Thestand-alone aspect is strengthened when the digital video is a localfile. This way, all of the content (HTML, keyframes, digital video)could be packaged up, compressed, and e-mailed to someone.

c. All metadata is cross-referenced/cross-linked based on time-codes.

d. Digital video is independent of the HTML representation—any digitalvideo source can be linked into the playback frame.

16. HTML Output Filter—Flowchart

FIG. 16 details a HTML export process 890 from the Video Cataloger. Thisprocess 890 is performed by module 564 identified in FIGS. 9 and 15.

The output process 890 starts at a begin step 892 and proceeds to step894 to process the session level metadata. This metadata is nottime-based, but rather is descriptive of the entire logging session. Thesession level metadata corresponds to the information 404 generated bythe Metadata Track Index Manager 402 shown in FIG. 7. The nature of thesession level metadata is a schema which may be defined by the user, inaddition to standard items such as the location where the video istaken. This information is encapsulated in an HTML frame 896 used toview this data on request, and is linked to the main HTML frame 916.

The next step is to process the keyframe track in step 898. Keyframeimages, which are captured raster images, may be converted to JPEGimages suitable for display in a web browser. JPEG is but one possibleviewable format. For convenience, the JPEG image files 900 may be storedin a separate subdirectory of the Cataloger file system. At step 902,the keyframe track is then further processed by constructing an HTMLkeyframe frame containing the keyframe time code information used toinvoke video playback in 896, and establishes hyperlinks directly to thecorresponding JPEG images 900.

Next, the close caption text track is processed in step 906. The cc-textis output into an HTML frame, with hyperlinks created from time-codesinto the keyframes of the HTML keyframe frame 904. This allows the userto click on cc-text elements, and invoke the corresponding set ofrelated keyframes.

Video Clips are processed in step 910. The clips (defined by in- andout-times, and a user defined set of text labels) are output into anHTML Clip frame 912. The time codes are used to establish hyperlinksinto the corresponding close caption text 908, and the correspondingkeyframes in keyframe frame 904.

Finally, a main HTML page that incorporates the above frames isconstructed in step 914. This HTML page embeds all the other frames fordisplay and navigation. A video play-out helper application to decodeand display video can be embedded in the web page frame. Examples ofhelper applications include RealPlayer (for RealVideo), Compcore SoftPEG(for MPEG) and Apple Quicktime.

Exemplary reference guides which could be uselful to write the code toautomatically generate HTML are HTML: The Definitive Guide, The secondEdition (1997) Chuck Musciano and Bill Kennedy , O'Reilly & Associates,Inc. and “Treat Yourself Web Publishing with HTML”, Laura LeMay, SamsPublishing, 1995, which are hereby incorporated by reference.

Note that this process flow is one example which incorporates a subsetof all available metadata tracks. The output process 890 described abovegenerated the exemplary screen shot in FIG. 17.

17. Example HTML Output—Screen Shot

Referring to FIGS. 16 and 17, a screen shot of the HTML output as seenat a client browser and as generated by the HTML output process 890(FIG. 16) will be described. Element 896 corresponds to the video framein the upper left portion of the screen display. Element 904 correspondsto the keyframe frame in the lower left portion of the screen display.Element 908 corresponds to the cc-text frame in the lower right portionof the screen display. Element 912 corresponds to the clip frame in theupper right portion of the screen display. Element 916 corresponds tothe whole browser window. As with most browsers, including MicrosoftExplorer and Netscape Navigator, if the displayable page is larger thanthe physical display, the browser will cause the page to be scrolled.Video data is retrieved by sending a time code to the embedded playerapplication. The player application then retrieves the video, seeks tothe requested time code (in-time), and begins playback. The user caninterrupt the playback using standard VCR type controls on the player.

The HTML code for an exemplary screen display is provided in theAppendix. Sheets A, B, C, D, E, G, H1, N and P are hereby incorporatedby reference in their entirety and can be found in the USPTO file forapplication Ser. No. 09/134,499. Sheet A of the Appendix lists thedirectory names (clip and icons) and file names at a top level. Sheet Blists the files in the clip directory, while sheets C, D and E list thefiles in the icons directory. Sheet F lists the HTML code for the toplevel index.html file which provides the framework for the display shownin the browser window 916 (FIG. 17). Sheet G lists the contents of thetopr.html file (as would be seen in the clip frame 912 (FIG. 17)). SheetH lists the contents of the video_label.html file. Sheet I lists thecontents of the video_mbase.html file. Sheet J lists the contents of thevideo_netshow.html file. Sheet K lists the contents of thevideo_noproxy.html file. Sheet L lists the contents of thevideo_ovs.html file. Sheet M lists the contents of the video_real.htmlfile. Sheets J, K, L, and M may be used to provide the proxy video toallow different video formats to be displayed in the video frame 896(FIG. 17). Sheet N lists the contents, including a set of keyframes andcorresponding timecodes (as would be seen in the keyframe frame 904(FIG. 17)), of the 000l.html file in the clips directory. Sheet P liststhe contents, including a set of icons in a closed-caption text frame(as would be seen in the cc-text frame 908 (FIG. 17)), of the 000r.htmlfile in the clips directory. The remaining sheets in the Appendix arealternate instances of the contents shown in exemplary sheets N and P.Of course, other programming languages besides HTML code could be usedto implement hyperlinked output conversion.

18. Alternative System

An alternate embodiment 940 of the video encoding process, whichinvolves a video server 942, is shown in FIG. 18. In this scenario,digital video is encoded in a MPEG stream on the Cataloger workstation111. The data stream is broadcast as a set of UDPs (Universal DatagramPackets) 946 on a specific port number (configurable). UDPs is astandard which is a member of the IP family of protocols. Whencataloging begins, the Video Cataloger 110 sends a START command 944 toa Vidsync process 260 which is running on the content server 140 wherethe video server software process 942 is running. Vidsync 260 in turntells the video server 942 to “start listening” for UDP packets 946 onthe specific port number. The video server 942 then begins “catching”the UDP packets 946, and converting the MPEG data into a digital videoasset on that server 942. As always, metadata 112 is sent from the VideoCataloger 110 to the metadata server 130 in parallel to this encodingprocess. When a STOP command 944′ is issued, Vidsync 260 signals thevideo server 942 to stop listening for the UDP packets 946.

In point of fact, the allocations of support hardware, computerworkstations and software processes are only described here as but oneexample. Many other functional partitions can be defined to implementthe present invention.

While the above detailed description has shown, described, and pointedout the fundamental novel features of the invention as applied tovarious embodiments, it will be understood that various omissions andsubstitutions and changes in the form and details of the systemillustrated may be made by those skilled in the art, without departingfrom the concepts of the invention.

What is claimed is:
 1. A video cataloging output filter, comprising: aplurality of metadata track processors each generating a distinct typeof metadata, wherein each processor converts at least one type ofmetadata representation of video information into a displayable frameand wherein at least one of the plurality of metadata track processorshyperlinks one type of metadata presented in the displayable frame withanother type of metadata displayable in another frame provided byanother metadata track processor; and a main frame processorincorporating the displayable frames of metadata into a displayble page.2. The filter of claim 1, additionally comprising a session level frameprocessor converting session level metadata to a displayable frame whichis hyperlinked via another frame.
 3. The filter of claim 1, wherein themetadata representations include at least one of: keyframe, closecaption and clip.
 4. The filter of claim 1, wherein the displayableframe is coded in HTML format.
 5. The filter of claim 1, wherein thedisplayable frames are linked with video information stored in a filesystem.
 6. The filter of claim 1, wherein the displayable frames arelinked in with video information communicated in a stream format.
 7. Thefilter of claim 1, additionally comprising a processor capable ofconverting keyframes to JPEG image files, and wherein one of themetadata track processors converts a keyframe metadata track and linksthe keyframe metadata track to the JPEG image files.
 8. A method ofbrowsing stored video information, comprising: displaying a page ofhyperlinked metadata within frames, each displayable frame beingindicative of a distinct type of metadata representation of stored videoinformation; selecting a link from one type of metadata presented in thedisplayable frame to another type of metadata displayable in anotherframe; selecting for display a portion of the video information based onthe metadata in one of the displayable frames; retrieving videoinformation stored as encoded digital data which corresponds to theselected portion of video information; and displaying the retrievedvideo information.
 9. The method of claim 8, wherein the encoded digitalvideo data and the displayable frames are stored in a common filesystem.
 10. The method of claim 8, wherein the retrieving of encodeddigital video data comprises receiving a video data stream from a videocontent server.
 11. The method of claim 8, wherein the video contentserver is remotely located and connected via the Internet.
 12. A videocataloging output subsystem, comprising: a plurality of metadata trackgenerators, wherein each generator generates a distinct type of metadatarepresentation of video information; a plurality of metadata trackprocessors, wherein each metadata track processor converts at least onetype of metadata representation of the video information into adisplayable frame, and wherein at least one of the plurality of metadatatrack processors hyperlinks one type of metadata presented in thedisplayable frame with another type of metadata displayable in anotherframe provided by another metadata track processor; and a main frameprocessor incorporating the displayable frames of metadata into adisplayable main fame.
 13. The subsystem of claim 12, wherein themetadata is hyperlinked based on time-codes corresponding to the video.14. The subsystem of claim 12, wherein the displayable main frame isdisplayed in a browser window.
 15. The subsystem of claim 12, whereinthe displayable frames are linked with video information stored in afile system.
 16. The subsystem of claim 12, wherein the displayableframes are linked with video information communicated in a streamformat.
 17. The subsystem of claim 12, additionally comprising a videoplayer for playing retrieved video information corresponding to aportion of the video information selected based on data in a metadatatrack.
 18. The subsystem of claim 17, wherein the video information isstored as encoded digital data.
 19. A system for browsing stored videoinformation, comprising: means for displaying a page of hyperlinkedmetadata within frames, each displayable frame being indicative of adistinct type of metadata representation of stored video information;means for selecting a link from one type of metadata presented in thedisplayable frame to another type of metadata displayable in anotherframe; means for selecting for display a portion of the videoinformation based on the metadata in one of the displayable frames;means for retrieving video information stored as encoded digital datawhich corresponds to the selected portion of video information; andmeans for displaying the retrieved video information.
 20. The system ofclaim 19, wherein the encoded digital video data and the displayableframes are stored in a common file system.
 21. The system of claim 19,wherein the means for retrieving of encoded digital video data comprisesmeans for receiving a video data stream from a video content server. 22.The system of claim 21, wherein the video content server is remotelylocated and connected via the Internet.
 23. The system of claim 19,wherein the link from one frame to another frame is within the page.